Why

The immediate use case for this is creating a canister (in another subnet). See "References". We'll want to know the ID of the created canister. This allows us to link to that datum from the proposal. Having this info will also facilitate testing this new proposal type.

In the not too distant future, this will also be used when taking a snapshot of an NNS-controlled canister.

Minor Associated Changes

Internally, added

trait CallCanisterReply {
  fn try_decode(...

next to existing CallCanister trait. Also, added

trait CallCanister {
    type Reply: CallCanisterReply;

This way, perform_call_canister knows how to decode the reply, instead of just throwing it away (it used to just throw the reply away).

perform_call_canister now also records the status of the proposal execution by calling set_proposal_execution_status. As a result, the body of all existing perform_whatever methods have been reduced to a single line:

self.perform_call_canister(proposal_id, request).await;

set_proposal_execution_status now takes Result<Vec<u8>, ...> instead of just Result<(), ...>. Actually, perform_call_canister doesn't directly decode the reply; it really happens here, in set_proposal_execution_status.

Existing callers of set_proposal_execution_status are mechanically updated from

self.set_proposal_execution_status(proposal_id, result);

to

self.set_proposal_execution_status::<()>(proposal_id, result.map(|()| vec![]));

Moved humanize_blob to a ic-nervous-system-string.

References

👈 Previous PR